The Unbound Array problem occurs when an embedded array in a MongoDB document grows indefinitely, causing performance degradation, index bloat, and risk of hitting the 16MB document size limit; solutions include referencing, the subset pattern, and bucketing.
The Unbound Array problem is one of the most common and dangerous schema design anti-patterns in MongoDB. It happens when you embed an array in a document that can grow without a fixed limit. While embedding related data is a powerful feature of MongoDB's document model, it becomes a liability when the array size is unbounded [citation:1][citation:2]. As the array grows, document size increases, index performance degrades, and eventually you risk hitting the hard 16MB BSON document size limit [citation:1][citation:2]. The Atlas Schema Advisor specifically flags collections where arrays exceed 10,000 entries [citation:6].
Unbounded arrays create multiple cascading problems. First, document size growth strains memory and I/O because MongoDB must load entire documents into RAM [citation:1]. Second, index performance degrades because multikey indexes on the array must maintain entries for every element; as the array grows, index scans become proportionally slower [citation:1]. Third, write amplification occurs because operations that modify the array (like $push) require rewriting the entire document, which becomes increasingly expensive [citation:5]. Finally, applications risk the 16MB document size limit, causing writes to fail completely when the array grows too large [citation:1][citation:5].
The most straightforward solution is to move the array to a separate collection and use references. This completely eliminates the unbounded growth because each related item becomes its own document [citation:1][citation:2]. Each document stays small, and you can query the related collection efficiently. The trade-off is that you may need $lookup aggregations to reunite the data, which adds query latency [citation:1][citation:4]. This is the right choice when the relationship is truly one-to-many and the 'many' side can grow arbitrarily large [citation:5][citation:7][citation:10].
For use cases where you only need a limited number of recent items (like displaying the 3 most recent reviews), the Subset Pattern is ideal [citation:2]. You embed a fixed-size subset of the most relevant data in the parent document, while storing the full history in a separate collection. This gives you fast access to the data you actually need while avoiding unbounded growth. This pattern works well when you have a natural recency requirement and updates to the subset are infrequent [citation:2][citation:9].
The Bucket Pattern is a hybrid approach where you group related items into fixed-size "buckets" [citation:7]. For example, instead of storing each user activity event as a separate document or as an infinite array, you create documents that contain, say, 100 events each. This gives you the best of both worlds: document size stays bounded, but you still get efficient access to groups of related data. This pattern is particularly effective for time-series data [citation:5][citation:7].
The right solution depends on your access patterns and constraints [citation:7][citation:10]. Choose referencing when you truly need to access all related items individually and the relationship can grow arbitrarily large [citation:1][citation:5][citation:10]. Choose the subset pattern when you only need a limited, recent slice of the data for display [citation:2]. Choose the bucket pattern for high-volume sequential data like logs, events, or time-series where you can group items naturally [citation:5][citation:7]. The MongoDB Schema Advisor now includes automated detection of unbounded arrays, highlighting collections where arrays exceed recommended sizes [citation:3][citation:6].
A classic unbounded array case is social media followers. Storing followers in an array within the user document is a disaster waiting to happen [citation:10]. With millions of users, a celebrity's document would quickly exceed 16MB. The solution is to create a separate follows collection with two fields: follower_id and following_id. This supports millions of followers without any document size risk, and indexes on both fields make queries efficient [citation:10]. This referencing approach scales linearly with data volume rather than exponentially.